Summary

Automated update of the libdatadog submodule to the latest HEAD.

Full CI result: ❌ 2 job(s) failed
CI pipeline: https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/119319187

libdatadog Integration Report

libdatadog SHA: 952c2ef75cdf7b2895d7152100ea61c12ccf4439
Analysis date: 2026-06-17

Overall status

✅ Clean update (no API changes required; the only persistent failures are flaky Windows job timeouts)

Build & test summary

The pipeline (119301593) finished with 2 persistent failures, both of the same kind:

Key observations:

• No compilation failures. tmp/artifacts/traces/ is empty — no job failed to compile against the new libdatadog. The Rust/C/FFI code built cleanly on every platform that produced a trace.
• The windows test_c job (.gitlab/generate-tracer.php:111) builds the extension with nmake inside the Windows container as its first step (.gitlab/generate-tracer.php:139) before running the test suite. Its timeout is 60m (.gitlab/generate-tracer.php:190). An API incompatibility would have aborted at the nmake step in minutes. Instead both jobs consumed the entire 60-minute wall-clock budget (3602 s ≈ 60 m 02 s) and were then killed — i.e. compilation succeeded and the PHP extension test suite (tests\ext) was still running when the clock expired.
• Only the two oldest PHP versions on Windows are affected. PHP 7.4 / 8.x on Windows, all Linux test_c, and the ASAN jobs passed. A libdatadog hang/deadlock in the FFI layer would be expected to affect every PHP version and Linux as well, not just Windows 7.2/7.3.
• The previous run of this pipeline reported 14 failures; this run is down to 2, and the retried ASAN test_c with multiple observers: [8.4] recovered on retry (it is not in the persistent-failure list). The two Windows jobs were also retried (tmp/artifacts/retried_jobs.tsv) and still hit the wall-clock limit — consistent with chronic Windows-runner slowness rather than a deterministic crash.

The windows test_c workload is heavy and slow on the Windows Server 2019 runners: it creates a NAT Docker network, starts three Windows containers (httpbin, request-replayer, and the build/test container), produces a debug build (configure.bat --enable-debug-pack, which is markedly slower), and then runs the full extension test suite. Debug builds on the oldest (slowest) PHP toolchains routinely sit near the 60-minute boundary, so a couple of them tipping over is expected variance.

Non-trivial changes made

No code changes required.

The new libdatadog SHA compiled and linked cleanly across all platforms (no compilation traces were emitted). None of the breaking changes in the changelog (e.g. VecMap span representation #2043/#2069, trace-buffer changes #2055/#2046, FFI error/response alignment #2029, crashtracking refactors) surfaced as a build break against dd-trace-php's call sites, so there was nothing to adapt.

Identified libdatadog issues

None identified.

There is no panic, regression, or behavioural change attributable to libdatadog. The failures are wall-clock timeouts in the CI infrastructure, not faults originating inside libdatadog.

Flaky / ignored failures

• windows test_c: [7.2] and windows test_c: [7.3] — both failed with failure_reason: job_execution_timeout, hitting the job's 60m limit exactly. These are timing/infrastructure failures (heavy Docker-on-Windows setup + debug build + full test suite on the slowest PHP toolchains), not libdatadog API or behaviour regressions. Per the classification rules, timing-based timeouts are treated as flaky and not fixed in code. Recommended action: re-run the two jobs; if they persistently sit at the 60-minute boundary, raise the windows test_c timeout or split the Windows matrix to give the oldest PHP versions more headroom — this is a CI-config concern, independent of the libdatadog bump.

/cc @bwoebi